THE LAN TUTORIAL SERIES PART 2: PROTOCOLS Definition The LAN Magazine "Glossary of LAN Terms" defines a protocol this way: A set of rules for communicating between computers. Protocols govern format, timing, sequencing and error control. Without these rules, the computer will not make sense of the stream of incoming bits. But there is more. Communicating data from computer to computer takes many steps. For example, suppose you are sending a file from one computer to another. The file has to be broken into pieces. The pieces have to be grouped in certain fashion. Information must be added to tell the receiver where each group belongs in relation to others. Timing information must be added. Error correcting information must be added, and so on. Because of this complexity, computer communication is usually broken down into steps. Each step has its own rules of operation, its own protocol. These steps must be executed in a certain order, usually from the top down on transmission and from the bottom up on reception. Because of this hierarchical arrangement, the term protocol stack is used to describe the different steps of computer communication. A protocol stack is simply a set of rules for communication, only it can be broken down into sets of rules for each step in the sequence. Protocols, Really What is a protocol, really? It is software that resides either in a computer's memory or in the memory of a transmission device like a network interface card. When data is ready for transmission, this software is executed. It prepares data for transmission and sets it in motion. At the receiving end, it takes the data off the wire and prepares it for the computer, taking off all the information added by the transmitting end. So, protocols are just software that performs data transmission. But there is more. Confusion is caused by the fact that there are many protocols, many different ways of getting data from one place to another. Novell does it one way. 3Com does it another. DEC does it a third way. And since the transmitter and the receiver have to "speak" the same protocol, these three can't talk directly to each other. That's where the term protocol standard and the OSI Model fit in. A protocol standard is a set of rules for computer communication that has been widely agreed upon and implemented by many vendors, users and standards bodies. Ideally, a protocol standard should, when implemented, allow people to talk to each other, even if they are using equipment from different vendors. Of course, you don't have to have a "standard" protocol to communicate. You can make up your own. The only problem is that you are limited to talking to yourself. Let's look at some of the protocol standards that exist and see if we can't get a feel for how protocols work. As you will see, there are many standards -- none of which can be called universal. The OSI Model The OSI Model is the best place to start because it is a full protocol stack. It is a set of protocols that attempt to define and standardize the entire process of data communications (some protocol standards only define part of the process). The OSI Model -- which stands for the Open Systems Interconnection Model of the International Standards Organization (ISO) -- has the support of most major computer and network vendors, along with many large customers and the U.S. government. The OSI Model is really nothing more than a concept, describing how data communications should take place. It divides the process into seven layers. Into these layers fit protocol standards developed by the ISO and by other standards bodies. At each layer, there are numerous protocols. That is, the OSI is not a single definition of how data communications actually takes place in the real world. It just says, "This is the way things should be divided and these are the protocols that you can use at each layer." As long as a network vendor chooses one of the protocols at each layer, the network should work with other vendors' offerings. Nobody really believes the hype that the OSI Model will lead to complete, transparent intercommunication between all computers. We are just hoping it is a step in the right direction. Each successive layer of the OSI Model works with the one below it. Remember, protocol stacks are not democratic; they are rigidly hierarchical. Each layer of the OSI Model is modular. That is, you may (theoretically) substitute one protocol for another at the same layer without affecting the operation of layers above or below. For example, you should be able to use a Token Ring board or an Ethernet board and still use all the other pieces of your network, including network operating system, transport protocols, internetwork protocols, applications interfaces, etc. Of course, vendors must create these products to the OSI Model specifications for this to work. The OSI Model's modularity should become clear as we describe the major protocols that conform to it. First a look at what each layer is supposed to do. 1. Physical Layer. The first, or Physical layer, of the OSI Model conveys the bits that move along the cable. It is responsible for making sure that the raw bits get from one place to another, no matter what shape they are in. It deals with the mechanical and electrical characteristics of the cable. 2. Data Link Layer. The second, or Data Link, layer of the OSI Model is responsible for getting data packaged and onto the network cable. It manages the physical transfer, providing the blocks of data, their synchronization, error control and flow control. The Data Link layer is often divided into two parts -- Logical Link Control (LLC) and Medium Access Control (MAC) -- depending on the implementation. 3. Network Layer. The third, or Network, layer of the OSI Model establishes, maintains and terminates connections. It is responsible for translating logical addresses, or names, into physical addresses. 4. Transport Layer. The fourth, or Tranport, layer of the OSI Model ensures data is sent successfully between the two computers. If data is sent incorrectly, this layer has the responsibility to ask for retransmission. 5. Session Layer. The fifth, or Session, layer of the OSI Model decides when to turn communication on and off between two computers. It coordinates the interaction between them. Unlike the network layer, it is dealing with the programs running in each machine to establish conversations between them. 6. Presentation Layer. The sixth, or Presentation, layer of the OSI Model does code conversion and data reformatting. It is the translator of the network, making sure the computer is talking in the right language for the network. 7. Application Layer. The seventh and final, or Application, layer of the OSI Model is the interface between the software running in the computer and the network. It supplies functions to the software in the computer, like electronic mail or file transfer. Unfortunately, protocols in the real world do not conform precisely to these neat definitions. Some network products combine layers. Others leave out layers. Still others break apart layers. But no matter what, all working network products achieve the same result, getting data from here to there. The question is, do they do it in a way compatible with the rest of the world's networks? More important, do they care? Popular Physical Protocols Hopefully, all of this will become clearer if we look at some real protocols and compare them to the OSI Model. The best known physical layer standards of the OSI Model (there are a few), are those from the IEEE, the Institute of Electrical and Electronic Engineers. That is, the ISO adopted some of the IEEE's physical network standards as part of its OSI Model. These are IEEE 802.3, or Ethernet, IEEE 802.4, or token- passing bus and IEEE 802.5, or Token Ring. These three standards define the physical characteristics of the network and how to get raw data from one place to another. Each is a Layer 1 standard. They also define how people can use the network at the same time without bumping into each other. Technically, this last part is a job for the Data Link layer, Layer 2. We will deal with this below. For now, let's see just what these standards mean. IEEE 802.3 defines a physical network that has a bus (straight line) layout. Data is broadcast throughout the network in no particular physical direction. All machines receive every broadcast, but only those meant to receive the data respond with an acknowledgement. Network access is determined by a protocol called Carrier Sense Multiple Access With Collision Detection, or CSMA/CD. It lets everyone send whenever they want. If they bump into each other, they back off, wait, and send again until they get through. Thus, the more users, the more crowded and slower the network -- like the freeway. (More on network access next month). IEEE 802.4 defines a physical network that has a bus layout. It is also a broadcast network. All machines receive all data but do not respond unless data is addressed to them. Network access is determined by a token that moves around the network in a logical fashion. It is broadcast to every machine but only the machine that is next for the token gets it. Once a machine has the token, and not before or after, it may transmit data. The MAP/TOP (Manufacturing Automation Protocol/Technical Office Protocol) standard uses this protocol. IEEE 802.5 defines a physical network that has a ring layout. Data moves around the ring from station to station. Each station regenerates the signal from the previous station. In this way it is not a broadcast network. The network access protocol is token-passing. The difference is that the token moves about in a ring, rather than over a bus. IBM, Texas Instruments and Ungermann-Bass are the only vendors of the chips needed to make Token Ring network interface cards. Nevertheless, it is fast becoming one of the most popular network hardware options. There are other Physical and Data Link layer standards, some that conform to the OSI Model and others that don't. The most famous that does not is Arcnet. It uses a token-passing bus access method, but not the same one as IEEE 802.4. A new physical standard called Fiber Distributed Data Interface (FDDI) is a 100M-bits-per-second physical protocol using token ring over fiber optic cable. It will probably be OSI-compatible. Data Link Protocols As we said, the IEEE protocol standards are not confined to the Physical layer but also work at the Data Link layer. We also said that the Data Link layer is often divided into two parts. The upper part is called Logical Link Control (LLC) and the lower part is called Medium Access Control (MAC). As it turns out, the IEEE standards define the lower, or MAC, half of the Data Link layer -- the part that determines how network users keep from bumping into each other. Medium Access Control is just what it sounds like. It is the protocol that determines which computer gets to use the network cable when many computers are trying. We saw that IEEE 802.3 lets everyone simply bump into each other and keep trying until they get through. IEEE 802.4 and 802.5 are more ordered, limiting conversation to the computer with the token. Remember, all of this is done in fractions of a second. So even when the network is crowded, no one really waits very long for access on any of the three types of networks. The other half of the Data Link layer, LLC, provides reliable data transfer over the physical link. In essence, it manages the physical link. There are two reasons why the IEEE split the Data Link layer in half (and why the ISO accepted it). First of all, the Data Link layer has two jobs to do. The first is to coordinate the physical transfer of data. The second is to manage access to the physical medium. Splitting the job allows for more modularity, and therefore flexibility. The second reason also has to do with modularity, but in a different way. The type of Medium Access Control has more to do with the physical requirements of the network than actually managing the transfer of data. In other words, the MAC layer is "closer" to the physical layer than the LLC layer. By splitting the two, it is possible to create a number of MAC layers (corresponding to physical layers) and just one LLC layer that can handle them all. This increases the flexibility of the standard. It also gives LLC an important role in providing an interface between the various MAC layers and the higher-layer protocols. By the way, Logical Link Control is the more common name of the IEEE's 802.2 specification. The numbers give it away. 802.2 works with 802.3, 802.4 and 802.5. It should also work with emerging standards, like FDDI. There are other protocols that perform the LLC functions. High-level Data Link Control (HDLC) is the protocol from the ISO. Like LLC, it conforms to the OSI model. IBM's SDLC (Synchronous Data Link Control) is a Data Link layer standard that does not conform to the OSI Model but does perform similar functions. IBM has many products that do not follow the OSI Model or its hierarchical setup. IBM has pledged support of OSI, however. Transport Protocols The ISO is in the process of establishing protocol standards for the middle layers of the OSI Model. As of yet, none of these have been implemented on a widespread basis, nor has the complete OSI protocol stack been established. To make matters more confusing, most of the middle-layer protocols on the market today do not conform neatly to the OSI Model's network, transport and session layers. They were created before the ISO started work on the model. The good news is many existing protocols are being incorporated into the OSI Model. Where existing protocols are not incorporated, interfaces between them and the OSI Model are being implemented. This is the case for TCP/IP, NetBIOS and APPC, the major middle-layer protocols available today. In the PC LAN environment, NetBIOS is the most important protocol. It stands for Network Basic Input/Output System. IBM developed it as a BIOS for networks. It is essentially a Session layer (Layer 5) protocol that acts as an applications interface to the network. It provides the tools for a program to establish a session with another program over the network. Hundreds of programs have been written to this interface, making it the most widespread protocol in the PC network arena. NetBIOS does not obey the rules of the OSI Model in that it does not talk only to the layers above and below it. As we said, programs can talk directly to NetBIOS, skipping the application and presentation layers. This doesn't keep NetBIOS from doing its job. It just makes it incompatible with the OSI Model, which is not the end of the world. Someone will write an interface between the two, soon. NetBIOS is limited to working on one network. Therefore, some network vendors have established an interface between NetBIOS and TCP/IP, a protocol from the Department of Defense for use over large combinations of networks (internetworks). TCP/IP stands for Transmission Control Protocol/Internet Protocol. TCP is a Transport protocol (Layer 4), corresponding to the definition we gave above. Its job is to get data from one place to another without errors. It forms an interface between the protocols above and below -- shielding the upper layers from concern about the connection and the lower layers from concern about transmission content. The IP protocol is for getting data from one network to another. Its main concern is bridging the differences between networks so they don't have to be modified to talk to each other. It does this by providing rules for the breakdown of data to conform with a given network. Gateways, which are the physical translators between networks, use IP's rules to take data from one network, modify it and route it correctly over another network. TCP/IP enjoys enormous support in government, scientific and academic internetworks. These computers use UNIX and other large-computer operating systems. In the past few years, business internetworks have begun to approach the size of those in government and universities. This has driven these businesses to look for internetwork protocol standards. They have found TCP/IP useful and it has become a de facto standard. Many see it as an interim solution until the OSI transport and internetwork protocols are finished. TCP/IP products for DOS-based networked PCs are also available. Often when TCP/IP is discussed, acronyms like SMTP, FTP and TELNET are tossed around. These are applications that have been written for TCP/IP and are widely used. They work at the Applications layer (Layer 7). SMTP stands for Simple Mail Transfer Protocol. FTP stands for File Transfer Protocol. TELNET is the name for a terminal emulation protocol. These protocols, written for TCP/IP, do exactly what they say they do. Advanced Program-to-Program Communications, or APPC, is another protocol for large networks. It comes from IBM and is part of Big Blue's Systems Network Architecture (SNA). It is similar to NetBIOS in that it provides an interface to the network for programs so they may communicate, but it is not limited to one network as is NetBIOS. APPC is geared toward mainframe computers, though IBM is offering it as part of its OS/2 Extended Edition. Using APPC, all computers communicate as peers, even PCs. Previously in the IBM world, PCs were forced to emulate terminals when communicating with mainframes. A number of other vendors, mini and micro, also offer APPC. APPC has received much publicity. Unfortunately, there are not many applications for APPC in the PC network arena. There are more in the minicomputer and mainframe network market. Nevertheless, IBM and others are promoting APPC as a protocol standard for the future. Its robustness, flexibility and reliability make it worth the extra development effort. There are other middle-layer protocols. XNS, IPX and NetBUEI are all transport protocols. XNS is short for Xerox Network System. It was one of the first local area network protocols used on a wide basis, mainly for Ethernet (802.3) networks. 3Com and many others use it. IPX is Novell's implementation of XNS. It is not completely compatible with the original, but very widely used. NetBUEI is IBM's transport protocol for its PC networking products. All of these protocols perform similar tasks. Many More If it seems like the number of protocols is idiotic, it is and it isn't. Different protocols have different advantages in different environments. No single protocol stack will work better than every other in every setting. NetBIOS seems to work fantastically in small PC networks but is practically useless for communicating with mainframes. APPC works well in mainframe environments. TCP/IP excels in large internetworks. On the other hand, much more is made about the differences in protocols than is actually warranted. Proprietary protocols are perfect solutions in many cases. Besides, if the proprietary protocols are widespread enough, they become standards, and gateways between them and other standards are built. This is happening with some of the major protocols we have not covered. These protocols include many de facto standards in minicomputer and scientific workstation communications. They include DEC's entire protocol suite, Sun Microsystems' NFS, AT&T's protocols and many others. We have also left out Apple's AppleTalk and AFP. While these enjoy widespread use, that use is based on the computers these companies are selling and not the proliferation of the protocols throughout the networking industry. Unfortunately, whether proprietary or standard, users are still faced with the dilemma of choice. This choice is made slightly easier by the shakeout and standardization that has occurred over the past few years at the lower Physical and Data Link layers. There are three choices, Token Ring, Ethernet or Arcnet. Right now, the same is happening at the higher layers. Can you guess which way things will go? -- Aaron Brenner